My main desktop has nicely started showing signs of degradation right after I made this PR, but I am still alive, and the main reason for this change is still around: Fail during configure step and not after XY files (hundreds in the best case) have already been compiled.

This works for both Linux (tested on Fedora and as far as I can tell Ubuntu has a very similar file listing for its related package) and cross-compilation to Windows from Linux (as long as SPIRV-Headers is installed via their cmake build system - it installs the files mentioned).

The only questions would be the Windows Vulkan SDK and NDK (if thought as a valid Vulkan target). I expect MoltenVK to not be a target for llama.cpp, as native Metal back-end seems to exist. It would be nice if the CI flow could be enabled, so these could be checked. I saw under docs that manual copying of files was recommended for some cases, so that may have to be adjusted so that such a check would pass. Alternatively, the check gets changed to be similar to the one in the actual file.

Ah, so MoltenVK indeed was a target - as that is the first thing to fail. Will check how that sysroot is handled.

edit: seems like the dependencies are not installed by the CI flow?

  ggml-ci-mac-vulkan:
    runs-on: [self-hosted, macOS, ARM64]

    steps:
      - name: Clone
        id: checkout
        uses: actions/checkout@v6

      - name: Test
        id: ggml-ci
        run: |
          vulkaninfo --summary
          GG_BUILD_VULKAN=1 bash ./ci/run.sh ~/results/llama.cpp ~/mnt/llama.cpp

Will have to check how and what the MoltenVK SDK (if that is what is being installed onto the system) contains.

Funnily enough the configure part of Windows + Vulkan CI flow seems to pass JustFine (https://github.com/ggml-org/llama.cpp/actions/runs/25050050776/job/73380477706?pr=22009#step:8:70)

edit2: Checked MoltenVK's SDK contents (https://github.com/KhronosGroup/MoltenVK/releases/tag/v1.4.1) and neither MoltenVK-macos.tar or MoltenVK-all.tar contains SPIRV-Headers it seems...

So I guess SPIRV-Headers was installed manually on this runner?

Alright, grabbed my old Intel Macbook and grabbed the latest Vulkan SDK from LunarG (trying to look at MoltenVK SDK was a mistake - got things confused)

find VulkanSDK/1.4.341.1/macOS -iname 'spirv-headers*'
# VulkanSDK/1.4.341.1/macOS/lib/pkgconfig/SPIRV-Headers.pc
# VulkanSDK/1.4.341.1/macOS/lib/cmake/SPIRV-Headers
# VulkanSDK/1.4.341.1/macOS/lib/cmake/SPIRV-Headers/SPIRV-HeadersConfig.cmake
# VulkanSDK/1.4.341.1/macOS/lib/cmake/SPIRV-Headers/SPIRV-HeadersConfigVersion.cmake

So the necessary files are included.

Then tested building this PR's branch and found out that it works as long as cmake is being told where to look (CMAKE_FIND_ROOT_PATH=~/VulkanSDK/1.4.341.1/macOS):

-- Found Vulkan: /Users/jeeb/VulkanSDK/1.4.341.1/macOS/lib/libvulkan.dylib (found version "1.4.341") found components: glslc glslangValidator 
-- Vulkan found

./CMakeCache.txt://The directory containing a CMake configuration file for SPIRV-Headers.
./CMakeCache.txt:SPIRV-Headers_DIR:PATH=/Users/jeeb/VulkanSDK/1.4.341.1/macOS/lib/cmake/SPIRV-Headers

The result compiles fine.

So I guess I can spy where Vulkan is found on the previous macOS Vulkan build runs, and see if I can make cmake search for things in its sysroot.

edit:

-- Found Vulkan: /usr/local/lib/libvulkan.dylib (found version "1.4.341") found components: glslc glslangValidator

So if this is properly packaged, -DCMAKE_FIND_ROOT_PATH=/usr/local should do it.

Two alternative takes on this would be:

1. pkg_check_modules, since SPIRV-Headers does seem to have a pc file. This would mean that PKG_CONFIG_{PATH,LIBDIR} would work, although upstream seems to install the pc file under share/ (probably since there is no library in the project). Alas, I've not seen too many people doing cross-compiles etc setting overrides towards it, so while I do personally prefer pkg-config as a method of finding libraries, in this case the cmake module seems like it would work more generally (as the search path set is the sysroot itself), plus pkgconf is usually not around for Windows MSVC users.
2. check_include_file, trying to just coast on the Vulkan cmake check to set the necessary search paths for the compiler.

When you use the SDK, you're supposed to source its setup-env file. If you've done that, cmake should find it with no manual configuration.

When you use the SDK, you're supposed to source its setup-env file. If you've done that, cmake should find it with no manual configuration.

Thanks for the information. I was just in general wanting to verify whether building with what I expect is going to be utilized by people would work. Do you happen to know whether this setup-env script is there on the macOS runner utilized for the Vulkan build?

If yes, we can source that in the CI script (although I think technically setting the search path would allow for other things to be found from that sysroot as well never mind, I mean I expect that script to just set the search variable so in that sense the result should be the same). If not, then what I added more or less should work. Although given that the CI is not allowed to run, I cannot validate whether the sysroot on the runner contains these cmake files (I would expect them to be there, but still).